[Previous] [Next] [Index]
[Thread]
Proposal for HTTP security requirements.
The attached document is a proposal for a requirements specification for
the IETF HTTP Security working group. <www-security@nsmx.rutgers.edu> is
the associated mailing list of the working group. For more information
about the IETF and the working group process please see
<http://www.ietf.cnri.reston.va.us/home.htm>.
Greg, Simon, Walt.
Rutgers WWW Security Team
==============================================================================
INTERNET-DRAFT G. Bossert
Expires August, 1995 S. Cooper
W. Drummond
Rutgers University Network Services
March, 1995
Requirements for HyperText Transfer Protocol Security
<draft-rutgers-httpsec-req-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. Distribution of
this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other than
as ``work in progress.''
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
Abstract
This document specifies the requirements for the provision of
security services to the HyperText Transport Protocol. These
services include confidentiality, integrity, user authentication,
and certification of servers/services, including proxied or
gatewayed services. Such services may be provided as extensions
to HTTP, or as an encapsulating security protocol. Secondary
requirements include ease of integration and support of multiple
mechanisms for providing these services.
1. Introduction
The use of the HyperText Transport Protocol [1] to provide
specialized or commercial services and personal or private data
necessitates the development of secure versions that include
privacy and authentication services. Such services may be
provided as extensions to HTTP, or as encapsulating security
protocols; for the purposes of this document, all such
enhancements will be referred to as HTTPSec.
In this document, we specify the requirements for HTTPSec, with
the intent of codifying perceived Internet-wide needs, along with
existing practice, in a way that aids in the evaluation and
development of such protocols.
HTTPSec is an enhancement to an object transport protocol. As
such, it does not provide independent certification of documents
or other data objects outside of the scope of the transfer of
said objects. In addition, security at the HTTPSec layer is
independent of and orthogonal to security services provided at
underlying network layers. It is envisioned that HTTPSec may
coexist in a single transaction with such mechanisms, each
providing security services at the appropriate level, with at
worst some redundancy of service.
1.1 Terminology
This following terms have specific meaning in the context of this
document. The HTTP specification [1] defines additional useful
terms.
Transaction:
A complete HTTP action, consisting of a request from the
client and a response from the server.
Gatewayed Service:
A service accessed, via HTTP or an alternate protocol, by the
HTTP server on behalf of the client.
Mechanism:
An specific implementation of a protocol or related subset of
features of a protocol.
2. General Requirements
HTTPSec must provide the following services:
o Confidentiality of the HTTP transaction.
o Authentication of the server/service.
o Authentication of the client/user.
o Integrity of the HTTP transaction.
These services must be provided independently of each other.
In addition, HTTPSec should conform to a number of secondary
requirements:
o Ease of integration with other features of HTTP.
o Support of multiple mechanisms for the above services.
These services and additional requirements are discussed in more
detail in the following sections.
3. Confidentiality
HTTPSec must provide confidentiality of the HTTP transaction, via
encryption of the HTTP messages.
The entire HTTP transaction must be considered private; thus, the
HTTP headers and data objects of client requests and server
responses must be confidential. Note: because the identity of
the object being requested is potentially sensitive, the URI/URL
of the request should be confidential; this is particularly
critical in the common case of form data or other user input
being passed in the URL.
4. Service Authentication
HTTPSec must support the authentication of the HTTP server to the
client.
HTTPSec should support the authentication of gatewayed services
to the client.
HTTPSec should support the authentication of the origin HTTP
server or gatewayed services regardless of intermediary proxy or
caching servers.
To allow user privacy, HTTPSec must support service
authentication without user authentication.
Because the identity of the object being requested is potentially
sensitive, service authentication should occur before any part of
the request, including the URI of the requested object, is
passed. In cases where the authentication process depends on the
URI (or other header data) of the request, such as gatewayed
services, the minimum necessary information to identify the
entity to be authenticated should be passed.
5. User Authentication
HTTPSec must support the authentication of the user to the
server.
HTTPSec should support the authentication of the client to
gatewayed services.
HTTPSec should support the authentication of the client to the
origin HTTP server regardless of intermediary proxy servers.
6. Integrity
HTTPSec must provide assurance of the integrity of the HTTP
transaction, including the HTTP headers and data objects of both
client requests and server responses.
7. Integration
In order to support integration with current and future versions
of HTTP, and to provide extendibility and independence of
development, the secure services provided by HTTPSec must be
orthogonal to and independent of other services provided by HTTP.
In accordance with the layered model of network protocols,
HTTPSec must be:
o independent of the content or nature of data objects being
transported
o implementable over a variety of connection schemes and
underlying transport protocols
8. Multiple Mechanisms
HTTPSec must be compatible with multiple mechanisms for
authentication and encryption. Support for multiple mechanisms
is required for a number of reasons:
o Accommodation of variations in site policies, including those
due to external restrictions on the availability of
cryptographic technologies.
o Support for a variety of applications and gatewayed services.
o Support for parallel implementations within and across
administrative domains.
To allow interoperability across domains, and to support the
transition to new/upgraded mechanisms, HTTPSec should provide
negotiation of authentication and encryption mechanisms.
References
[1] T. Berners-Lee, R. T. Fielding, and H. Frystyk Nielsen.
"Hypertext Transfer Protocol -- HTTP/1.0" Internet-Draft
<URL:gopher://ds1.internic.net/00/internet-drafts/
draft-ietf-http-v10-spec-00.txt>, November 1994.
[2] G. Bossert, S. Cooper, W. Drummond. "Requirements of Secure
Object Transfer Protocols" Internet-Draft
<URL:http://www-ns.rutgers.edu/www-security/draft/
draft-rutgers-sotp-requirements-00.txt>, March 1995.
Pending submission to the IETF, this document may be found at
<URL:http://www-ns.rutgers.edu/www-security/draft/
draft-rutgers-httpsec-requirements-00.txt>
Acknowledgments
The authors would like to acknowledge the useful discussions of
members of the www-security@nsmx.rutgers.edu mailing list and the
proposed HTTPSec IETF working group on issues of HTTP security.
Eric Rescorla of EIT <ekr@eit.com> provided valuable comments on
an early draft of the Requirements of Secure Object Transfer
Protocols draft [2], a principal influence on this document.
Security Considerations
As noted above.
Author's Addresses
Greg Bossert -- bossert@noc.rutgers.edu
Simon Cooper -- scooper@noc.rutgers.edu
Walt Drummond -- drummond@noc.rutgers.edu
Network Services, Telecommunications Division,
Rutgers University Computing Services
Hill Center, Brett Road, Bush Campus
Piscataway, New Jersey 08855-0879 USA
Voice: 908-445-TDNS
Fax: 908-445-2968
$Id: draft-rutgers-httpsec-requirements-00.txt,v 1.6 1995/03/29 22:32:31 bossert Exp $